User interface for accessing virtual viewpoint animations

ABSTRACT

A user such as a television viewer is provided with the capability to view an event from different virtual viewpoints which differ from the viewpoint of a camera. In one aspect, the user is informed of particular camera images from which a virtual viewpoint can be viewed. For example, a menu interface may provide thumbnail preview images of the one or more particular camera images. In another aspect, the use enters commands to manipulate a virtual viewpoint, such as by rotating around a point, moving a lookout point and zooming in or out. In response, a display is provided which includes a textured 3d model of the event combined with at least one textured object in the event. For instance, the event may be a sporting event and the at least one textured object may be a participant in the sporting event.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. provisional pat. app.60/988,725, filed Nov. 16, 2007, titled “Changing The Perspective Of ACamera In An Image,”, incorporated herein by reference.

BACKGROUND OF THE INVENTION

Various techniques have been developed for enhancing video broadcasts oflive events. Broadcasts can be enhanced to assist the human viewer infollowing the action of the live event as well as providingentertainment and educational benefits. For example, a replay of aparticular event, such as the scoring of a goal in a soccer match, canassist the viewer in comprehending the finer points of the game,including the movement and positioning of the players. However, replaysare conventionally limited to depicting the viewpoint of one or morecameras. Due to safety and practical considerations, cameras cannotalways be positioned in locations which capture the action from adesired viewpoint. As a result, the images obtained may not capture themost important action, for instance, due to one player occludinganother.

SUMMARY OF THE INVENTION

The present invention addresses the above and other issues by providinga system and method for providing images of a live event from differentvirtual viewpoints.

One embodiment involves informing a user of particular camera imagesfrom which a virtual viewpoint can be viewed. For example, a method forproviding image data of an event includes receiving video data of theevent, where the video data includes camera images of the event, andreceiving auxiliary data associated with the video data. The auxiliarydata identifies one or more particular camera images of the cameraimages from which at least one virtual viewpoint of the event can beviewed. The method further includes, responsive to the auxiliary data,informing a user of the one or more particular camera images of thecamera images from which the at least one virtual viewpoint of the eventcan be viewed.

In another embodiment, a system for providing image data of an eventincludes at least one processor-readable storage device which storesprocessor-readable code, and at least one processor which executes theprocessor-readable code to perform a method. The method includesreceiving video data of the event, where the video data includes cameraimages of the event, and receiving auxiliary data associated with thevideo data. The auxiliary data identifies one or more particular cameraimages of the camera images from which at least one virtual viewpoint ofthe event can be viewed. The method further includes, responsive to theauxiliary data, informing a user of the one or more particular cameraimages of the camera images from which the at least one virtualviewpoint of the event can be viewed.

Another embodiment involves enabling a user to manipulate a virtualviewpoint. For example, a method for providing image data of an eventincludes receiving video data of the event, where the video dataincludes camera images of the event and receiving a user request, via auser interface, to view at least one virtual viewpoint of the event fromone or more particular camera images of the camera images. The methodfurther includes, in response to the user request, displaying a textured3d model of the event combined with at least one textured object in theevent, to depict the at least one virtual viewpoint. The textured 3dmodel and the at least one textured object are textured using at leastone camera-capture image of the event.

In another embodiment, a system for providing image data of an eventincludes at least one processor-readable storage device which storesprocessor-readable code, and at least one processor which executes theprocessor-readable code to perform a method. The method includesreceiving video data of the event, where the video data includes cameraimages of the event and receiving a user request, via a user interface,to view at least one virtual viewpoint of the event from one or moreparticular camera images of the camera images. The method furtherincludes, in response to the user request, displaying a textured 3dmodel of the event combined with at least one textured object in theevent, to depict the at least one virtual viewpoint. The textured 3dmodel and the at least one textured object are textured using at leastone camera-capture image of the event.

Corresponding methods, systems and processor readable storage devicesare provided.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts a system for capturing and processing images from anevent.

FIG. 2 depicts a relationship between camera, image and world coordinatesystems.

FIG. 3 a depicts camera and processing facility components forprocessing images.

FIG. 3 b depicts a user system for accessing an animation.

FIG. 4 is a block diagram of one embodiment of a system which includes aconventional camera and a high resolution camera.

FIG. 5 a depicts a line finder and repair process.

FIG. 5 b depicts a process for finding straight lines in the line finderand repair process of FIG. 5 a.

FIG. 5 c depicts a process for finding curved lines in the line finderand repair process of FIG. 5 a.

FIG. 5 d depicts a mask image showing field lines and players in asporting event.

FIG. 5 e depicts an image showing center points of masked image segmentsof the image of FIG. 5 d.

FIG. 5 f depicts an image showing straight lines which connect centerpoints of the image of FIG. 5 e.

FIG. 5 g depicts an image showing a curved line which connects centerpoints of the image of FIG. 5 e.

FIG. 5 h depicts an image showing pixel widths along straight and curvedlines of the image of FIG. 5 e.

FIG. 5 i depicts an image showing removal of an object which occludes astraight line of the image of FIG. 5 h.

FIG. 5 j depicts an image showing removal of objects which occludestraight and curved lines of the image of FIG. 5 h, and repair of thelines.

FIG. 6 a depicts a player finder process.

FIG. 6 b depicts a video image showing bounding boxes of players whichare detected by the process of FIG. 6 a.

FIG. 6 c depicts a video image after an operator has separated out twoplayers from a common bounding box which was provided by the process ofFIG. 6 a.

FIG. 6 d depicts a color matte image of the video image of FIG. 6 b.

FIG. 6 e depicts a user interface which includes the video image of FIG.6 b and a camera registration schematic.

FIG. 7 a depicts a process for building a missing portion of an occludedplayer.

FIG. 7 b depicts a user interface for building a missing portion of anoccluded player.

FIG. 7 c depicts a user interface showing a player with a missingportion and a library of images for providing the missing portion.

FIG. 7 d depicts the user interface of FIG. 7 c showing a selectedlibrary image combined with the player with the missing portion.

FIG. 7 e depicts the user interface of FIG. 7 d after repairing theplayer with the missing portion.

FIG. 8 a depicts a process for building an animation.

FIG. 8 b depicts a process for providing a presentation.

FIG. 8 c depicts a process for providing a presentation using cameraswith different viewpoints.

FIG. 8 d depicts a process for providing a presentation using standardand high resolution images.

FIG. 8 e depicts a user interface for repairing a playing field.

FIG. 8 f depicts the user interface of FIG. 8 e after the playing fieldhas been repaired.

FIG. 9 a depicts details of a process for rendering virtual viewpoints.

FIG. 9 b depicts a process for rotating and fading out players based onan angle of a virtual viewpoint.

FIG. 9 c depicts a process for texturing a 3d model.

FIG. 9 d depicts a user interface for providing a texture of a 3d model.

FIG. 9 e depicts an initial image in an animation from a virtualviewpoint which corresponds to the perspective of a camera viewpoint.

FIG. 9 f depicts a second image in an animation which is obtained from avirtual viewpoint which is to the left of the camera viewpoint of FIG. 9e.

FIG. 9 g depicts a third image in an animation which is obtained from avirtual viewpoint which is to the right of the camera viewpoint of FIG.9 e.

FIG. 9 h depicts the third image of FIG. 9 g in which one of the playersis replaced by a marker.

FIG. 10 a depicts a process for enabling a user to run an animation.

FIG. 10 b depicts a user interface which allows a user to select fromavailable animations.

FIG. 10 c depicts a user interface which allows a user to run ananimation.

FIG. 10 d depicts a user interface which allows a user to select acamera viewpoint for an animation.

DETAILED DESCRIPTION

The present invention provides a system and method for providing imagesof a live event from different virtual viewpoints.

FIG. 1 depicts a system for capturing and processing images from anevent. One possible example of an event is a live event such as asporting event, e.g., a soccer match which is played on a field 102 in astadium 100 or other event facility. Although a soccer match isdiscussed as an example, the techniques discussed herein are suitablefor use with other sporting events as well, such as football, rugby,track and field events, baseball, basketball, tennis, hockey, lacrosse,ice skating, dancing exhibitions and so forth. Further, the techniquesdiscussed herein are suitable for use with other live events besidessporting events. The techniques discussed herein are also suitable forprior recorded events of any type.

Cameras C1-C6 are positioned at different locations around the field 102to capture images of the live event. The arrangement of cameras shown isan example only. Other views, including overhead views, views from thegrandstands, and so forth can also be provided. Moving cameras can alsobe used.

The cameras C1-C6 can be television broadcast cameras, for instance,which capture thirty frames or sixty fields per second, in one possibleapproach. In an example implementation, HD-SDI 720p video uses 60frames/sec. While such cameras sense visible light, it is also possibleto use cameras that sense electromagnetic radiation outside a range ofvisible light, such as infrared radiation, depending on the application.Further, note that other rates of image capture can be used. Thelocation of objects in the live event, such as players or portions ofthe field, can be described in terms of a world coordinate system 130,also known as a free space coordinate system, which is fixed relative tothe earth or other environment of interest, in one approach. The worldcoordinate system 130 includes orthogonal directions represented by a wyaxis, a wx axis, and a wz axis which extends out of the page. An originof the world coordinate system can be chosen to be at a specifiedlocation relative to the event facility 100. Or, the origin can be milesaway from the event. Other world coordinate systems whose axes are notorthogonal are also possible, including for example coordinate systemswhich use latitude, longitude and elevation, spherical coordinatesystems and so forth.

Each camera can be provided with sensors which detect intrinsic andextrinsic parameters of the camera when these parameters are variable.Intrinsic parameters, such as focal length, lens distortion and zoomsetting represent characteristics of the camera design and settings, anddo not depend on the position and orientation of the camera in space.Extrinsic parameters, such as tilt or pan, depend on the position andorientation of the camera in space. Such sensors can be provided usingtechniques known to those skilled in the art. For example, pan and tiltsensors can be attached to a tripod on which the camera is mounted. See,e.g., U.S. Pat. No. 5,912,700, issued Jun. 15, 1999, incorporated hereinby reference. The sensors can be used to determine the field of view ofthe camera, e.g., where the camera is pointing and what it can see.

It is also possible to determine camera extrinsic and intrinsicparameters without sensors, e.g., as described in Tsai's method. See,e.g., Tsai, Roger Y., “An Efficient and Accurate Camera CalibrationTechnique for 3D Machine Vision,” Proc. of IEEE Conf. on Computer Visionand Pattern Recognition, Miami Beach, Fla., 1986, pp. 364-374. Forexample, one approach to determine the intrinsic and extrinsicparameters of a camera involves placing marks in various measured orknown locations in the event facility such that each mark looksdifferent and at least one mark will always be visible to the camerawhile the camera is pointed at the event facility. The marks could lookidentical and be distinguished through other means such as arrangementor triggering/flashing. A computer using optical recognition technologycan find the mark in the video frame and, based on the mark's size andposition in the video frame, determine the camera parameters. Anotherapproach to determining intrinsic and extrinsic parameters of a camerainvolves placing marks in various measured or known locations in theevent facility such that each mark looks different, but the marks may beremoved after camera parameters have been determined. A computerimplementing a camera parameter estimation algorithm based on manualuser interaction rather than, or in addition to, pattern recognition candetermine camera parameters. It is also possible to determine cameraparameters from an image containing no special marks but containingidentifiable features each of whose position in space is measured at anytime prior to determining camera parameters.

The cameras capture images and communicate the images in analog ordigital signals by wire or other link to a processing facility 110,which can be a mobile facility parked at or near the event facility 100,in one possible approach. The processing facility 110 includes equipmentwhich receives and stores the captured images, and processes thecaptured images, such as to provide an animation, as discussed furtherherein. In one approach, the animation can depict different virtualviewpoints of the live event from a single image from a camera, or frommultiple images from multiple cameras. The virtual viewpoints can differfrom the viewpoint of the camera. This allows the live event to be seenfrom viewpoints which are not otherwise available. The processingfacility 110 can subsequently transmit the video, via an antenna 120 oroptical fiber, etc., to another location such as a television broadcastfacility for broadcast to viewers in their homes. In another approach,the processing facility can be remote from the event facility 100. Ananimation could also be created in a studio or even at the viewer'shome, e.g., via a set top box.

Although examples are provided which involve broadcasts of televisionsignals, images can similarly be communicated to end users via a networksuch as the Internet, or a cell phone network, to computing devices suchdesktop computers, laptops, cell phones with image renderingcapabilities, portable digital assistants and the like. In one approach,the images are streamed to a computing device. The images can similarlybe downloaded as one or more files from a server. It is also possible totransmit the animation (or data to compute the animation) via a separatemechanism or channel from that which transmits the video “program”.

FIG. 2 depicts a relationship between camera, image and world coordinatesystems. A camera coordinate system 210, which includes orthogonal axesX_(C), Y_(C) and Z_(C) in three dimensions, is fixed relative to thecamera. The origin of the coordinate system may be at the front nodalpoint of the lens, in one possible approach, modeling the camera as apinhole camera. An image coordinate system 220, also referred to aspixel space, includes orthogonal axes X and Y in two-dimensions, and isfixed relative to a captured image 200. A world coordinate system 230,which includes orthogonal axes X_(W), Y_(W) and Z_(W), is fixed relativeto, e.g., the earth, the site of a live event such as a stadium, orother reference point or location. The position and/or path of theobject 240 can be determined in the world coordinate system 230 in onepossible approach, e.g. using GPS data or other approaches. The line ofposition 212 is an imaginary line which extends from the camera position(which in this case is at the origin of the camera coordinate system210) through a pixel in the image 200, intersecting the pixel at a point225, and through the object 240. Each pixel in the image 200 correspondsto a different line of position. Point 225 in the captured image 200represents the location of the object 240 in the image. The location ofthe object in the image 200 can be represented by coordinates (sx, sy)in a coordinate system which has its origin at a corner of the image, inone approach. The coordinates may identify the center of the object.

Further, the line of position can be represented by a vector (LOP) whichhas unity magnitude, in one approach. The vector can be defined by twopoints along the LOP. The vector can be represented in the worldcoordinate system 230 using an appropriate transformation from the imagecoordinate system.

The Z_(C) axis of the camera coordinate system, which is the opticalaxis 214 of the camera, intersects the captured image at a pointrepresented by coordinates (0_(x), 0y). A two-dimensional coordinatesystem extending from (0_(x), 0_(y)) can also be defined.

The camera registration process involves obtaining one or moretransformation matrices or functions which provide a conversion betweenthe image coordinate system 220 and the world coordinate system 230. Thetransformation functions may include non-linear functions, for examplein transforming pixel coordinates from a distorting lens to undistortedpositions. Further information can be found in E. Trucco and A. Verri,“Introductory techniques for 3-D computer vision,” chapter 6, PrenticeHall, 1998, U.S. Pat. No. 5,912,700, issued Jun. 15, 1999, and U.S. Pat.No. 6,133,946, issued Oct. 17, 2000, each of which is incorporatedherein by reference. In one approach, we can use a Levenberg-Marquardtalgorithm non-linear optimizer to compute camera parameters given thepixel locations of known 3D features.

FIG. 3 a depicts camera and processing facility components forprocessing images. The computer system 300 is a simplifiedrepresentation of a system which might be used at the processingfacility 110 (FIG. 1), for instance. The computer system 300 includes astorage device 310 such as a hard disk or portable media, a networkinterface 320 for communicating with other computer systems via a link322, a processor 330 for executing software instructions, a workingmemory 340 such as RAM for storing the software instructions after theyare loaded from the storage device 310, for instance, an example camerainterface 350 (in practice, more than one may be used), and a userinterface display 360.

The storage device 310 may be considered to be a processor readablestorage device having processor readable code embodied thereon forprogramming the processor 330 to perform methods for providing thefunctionality discussed herein. The user interface display 360 canprovide information to a human operator based on the data received fromthe camera via the interface 350. The user interface display 360 can useany known display scheme, whether graphical, tabular or the like. Inaddition to an on-screen display, an output such as a hard copy fromprinter can be provided to report results. Results can also be reportedby storing data at the storage device 310 or other memory, e.g., forlater use.

An example camera 370 includes extrinsic parameter sensors 372 andintrinsic parameter sensors 374. The extrinsic parameter sensors 372 canidentify an orientation of the camera, such as a pan and tilt of thecamera. The intrinsic parameter sensors 374 may identify a zoom setting,whether an extender is used and so forth. The camera 370 communicatesimage data, whether analog or digital, in addition to data from theextrinsic parameter sensors 372 and the intrinsic parameter sensors 374to the computer system 300 via the camera interface 350. It is alsopossible to determine camera extrinsic and intrinsic parameters withoutsensors 372 or 374, as described above in reference to Tsai's method.

Further, the functionality described herein may be implemented using oneor more processor readable storage devices having processor readablecode embodied thereon for programming one or more processors to performthe processes described herein. The processor readable storage devicescan include computer readable media such as volatile and nonvolatilemedia, removable and non-removable media. By way of example, and notlimitation, computer readable media may comprise computer storage mediaand communication media. Computer storage media includes volatile andnonvolatile, removable and non-removable media implemented in any methodor technology for storage of information such as computer readableinstructions, data structures, program modules or other data. Computerstorage media includes, but is not limited to, RAM, ROM, EEPROM, flashmemory or other memory technology, CD-ROM, digital versatile disks (DVD)or other optical disk storage, magnetic cassettes, magnetic tape,magnetic disk storage or other magnetic storage devices, or any othermedium which can be used to store the desired information and which canbe accessed by a computer. Combinations of any of the above are alsoincluded within the scope of computer readable media.

FIG. 3 b depicts a user system for accessing an animation. In oneaspect, a user such as a television viewer can access information forviewing an animation from a television broadcast or other data. In oneapproach, auxiliary information for providing the animation is providedwith the television broadcast. In another approach, the auxiliaryinformation is provided via another channel such as a computer network.Data for providing a user interface which allows the user to access,manipulate and/or create an animation can also be provided. The usersystem 380 can include a network interface 382 for receiving data from,and optionally communicating data to, one or more networks, such as atelevision broadcast network and/or a computer network. A set-top box386, digital video recorder 388, display 390, host computer 392 and userinput device 394, such as a handheld remote control, mouse or otherpointing device, or keyboard, can also be provided. See also FIGS. 10a-d and the associated discussion.

FIG. 4 is a block diagram of one embodiment of a system which includes aconventional camera and a high resolution camera. For further details,see U.S. patent application Ser. No. 11/467,467, filed Aug. 25, 2006,titled “Video Effect Using Movement Within an Image”, incorporatedherein by reference. The use of a high resolution camera to providevirtual viewpoints can allow zooming in without getting blurry, comparedto a standard resolution camera, since additional detail is captured. Inone possible approach, a high resolution digital camera is co-locatedwith a broadcast video camera, such as C1-C6 in FIG. 1. From thislocation the video/image/data will be transmitted to a production center420, which can be in the processing facility 110, for instance, overfiber, coax or other transmission medium.

The system includes components at the camera location 410 and theproduction center 420. Camera location 410 can include a cameras beingused to broadcast an event. It is contemplated that there can bemultiple cameras broadcasting a live event and, thus, there will bemultiple instances of the hardware components of camera location 410 incommunication with production center 420.

Camera location 410 includes a digital still camera 430 and a broadcastvideo camera 432. Digital still camera 430 is in communication withcamera interface 434. In some embodiments, digital still camera 430 ismounted on the lens (or otherwise attached to the camera) for broadcastvideo camera 432. In other embodiments, digital still camera 430 can belocated near video camera 432. For example, digital camera 430 can berigidly mounted, so that it is not able to pan or tilt, on a wall,platform, handrail, etc. very close to the broadcast video camera 432.One example of a suitable digital still camera is the Canon 1DsMKII. Inone embodiment, each of the images captured by the digital still camera430 comprises eight or sixteen megapixels. Broadcast camera 432 can beany suitable broadcast camera.

In other embodiments, instead of using a digital still camera, camera430 can be a digital video camera which outputs video images at a fixedinterval. In yet another embodiment, camera 430 can be another type ofsensor that can provide electronic images to computer 440. In oneexample, camera 430 can be an analog broadcast camera and camerainterface 434 can convert the analog video signals to digital videoimages or other types of electronic images.

In other embodiments, instead of using a digital still camera, camera430 can be omitted and camera 432 can be a very high resolution cameraconnected to the camera interface 434 (as well as the connection tocomputer 440), which can have a large recording capability.

Furthermore, more than two cameras may be used. For example, one maywish to set two video cameras 180 degrees apart and several digitalstill cameras between to help create the virtual views between the videocameras. More than two video cameras can be used as well, which wouldgive the operator a choice of which video to use for the leading andtrailing video. Or, a single video camera can be used, with multiplestill cameras placed to expand the effective range of the virtual views.Also, the digital still cameras may be used because of lower cost oreasier setup instead of higher resolution.

Production center 420 includes a computer 440 with suitable processors,video card and Ethernet card. Broadcast video camera 432 sends itsimages to the video card (or other interface) on computer 440, e.g., at30 or 60 frames per second. Computer 440 stores the received video aselectronic digital video images. Each of the frames will be stored in avideo buffer on a hard disk for computer 440. In one embodiment, thevideo buffer holds fifteen seconds of HD video or thirty seconds of SDvideo.

Computer 440 includes a monitor 442 and keyboard/mouse 444, all of whichare used to implement the user interface. Camera 432 is connected to amonitor 460 which displays the video received from camera 432. Computer440 is also connected to a monitor 462 for showing the output video. Theoutput video is also provided to a video recorder 464. From the videorecorder, the output video can be provided for broadcasting as part ofthe television production of the event being captured by broadcast videocamera 432.

Camera interface 434 is used to control digital camera 430 and receiveimages from digital camera 430. Camera interface 430 sends the digitalimages to computer 440 via either a fiber data line 446 or a coaxialdata line 448 or other transmission media. The fiber optic line fromcamera interface 434 is connected to a converter 450, which convertsfiber data to Ethernet and provides the information to an Ethernet cardfor computer 440. Data sent on coaxial line 448 is sent through a filter(e.g., Humbucker filter) which filters out 60 cycle noise. The output ofthe filter is sent to a cable modem which provides the data to theEthernet card for computer 440

A trigger switch 436 is connected to camera interface 434. An operatorat production center 420 can push the trigger switch 436 in order totrigger camera 430 to take a picture. In one embodiment, the triggerswitch can be located at the camera location 410. In another embodiment,instead of using trigger switch 436, the camera 430 will automaticallytake pictures at a set interval.

In another embodiment, an additional computer can be used at theproduction center 420 as a video server, receiving the video from camera432 and storing all of the video for an event on a hard disk drive orother storage medium. This video server will synchronize its time withcomputer 440 via an Ethernet connection. Each frame (or field or otherunit) of video stored will be provided with a time stamp by the videoserver. Similarly, computer 440 will add the offset between computer 440and the video server to the data for the still images corresponding intime. When an animation is being created, as described below, computer440 will access the necessary frame or frames of video from the videoserver.

FIG. 5 a depicts a line finder and repair process. Note that in this andother flowcharts the steps shown need not necessarily occur as discretesteps or in the order shown. To create an animation which depictsdifferent virtual viewpoints of a live event, such as a sports eventwhich is played on a field or other surface which includes markings suchas boundary and field of play lines, it can be helpful to automaticallydetect and repair portions of the lines which may be occluded in a givenimage by players or other objects. Generally, such lines may appear aswhite chalk lines on a green grass field, black tape lines on a woodbasketball court, and so forth. If the lines are not repaired, they mayappear as artifacts in different virtual viewpoints, reducing therealism. For example, see also FIG. 5 d, which depicts an image 550 inwhich a curved line, including portions 554 and 555, is partly occludedby a player 556, and a straight line including portions 552 and 553 isoccluded by a player 558. Note that these and other figures are notnecessarily to scale. For example, the lines may be thinner relative tothe players.

Step 500 of FIG. 5 a begins the line finder and repair process. Step 502includes capturing an image of a live event. Generally, this is an imagefor which it is desired to provide an animation with different virtualviewpoints of the event, such as an image showing the scoring of a goalin a soccer match or other key play. An operator can designate thespecific image which is to be used from among the captured images, e.g.,from the video of a conventional video camera or from an image providedby a special high resolution camera. Step 504 includes providing a maskimage. For example, the mask image may be a black and white image inwhich the grass of the playing field is black and the lines are white.FIG. 5 d depicts a mask image showing field lines and players in asporting event. The penalty area of a soccer field is depicted. Here,for illustrative purposes, the grass area is also shown as white insteadof black. Step 506 includes finding centers of the masked imagesegments, e.g., the field lines and players. Generally, the field linesand players have a thickness of more than one pixel. Vertical andhorizontal scanning can be used to determine center points of the fieldlines and players or other objects. For example, intersections of pointsobtain by the vertical and horizontal scanning can yield the centerpoints. FIG. 5 e depicts an image 560 showing center points of maskedimage segments of the image of FIG. 5 d. Each dot, such as dot 562,represents a center point. In practice, many more center points thanthose shown can be obtained.

Step 508 includes finding straight lines in the masked image segments,as discussed further in connection with FIG. 5 b. For example, FIG. 5 fdepicts an image 570 showing straight lines which connect center pointsof the image of FIG. 5 e. For example, straight lines 571 and 572 arefound in line portions 552 and 553, respectively. Straight lines 573,574, 575 and 576 are also detected. Note that straight lines 573 and 574appear generally as straight lines in the image from the viewpointshown, although they would appear as curved lines from an overhead view.

Step 510 includes finding curved lines in the masked image segments, asdiscussed further in connection with FIG. 5 c. For example, FIG. 5 gdepicts an image 580 showing a curved line 581 which connects centerpoints of the image of FIG. 5 e, including example center points 582 and583.

Step 512 includes finding an average pixel width of all lines, e.g.,including curved and straight lines. The pixel width is taken in adirection which is perpendicular to the length of each line. Thus, eachline can be traversed in increments and the pixel width taken for eachincrement. The pixel widths can then be summed and divided by the numberof readings to obtain the average.

Step 514 includes determining if a mask width for a line is greater thanthe average pixel width by a margin, e.g., by 25%, in which case anassumption is made that the line is obscured. For example, FIG. 5 hdepicts an image 590 showing pixel widths along straight and curvedlines of the image of FIG. 5 e. As can be seen, the pixel widths of lineportions 552 and 553 are about the same, while the pixel width in theregion of the player 558 is much greater. As a result, it can bedetermined that the line which includes the portions 552 and 553 isoccluded by the player 558. Similar processing can determine that acurve which includes the portions 554 and 555 is occluded by the player556.

Step 516 includes checking intensity and gradient values of theremaining line pixel slices and removing them if greater than the normby a margin. The intensity and gradient values may be from the Houghtransform which can be used in step 508 and 510.

Step 518 includes changing the player mask to remove the found linepixels. For example, FIG. 5 i depicts an image 592 showing removal of anobject (e.g., player 558) which occludes a straight line of the image ofFIG. 5 h. Removal of the player creates a gap 593 between the straightline portions 552 and 553.

Step 520 includes drawing obscured lines into the background image usinga nearby good line slice. For example, FIG. 5 j depicts an image 595showing removal of objects which occlude straight and curved lines ofthe image of FIG. 5 h, and repair of the lines. Here, repaired lineportions 597 and 596 are depicted. Straight line portion 596 can beprovided by filling in pixel data between the straight line portions 552and 553, while curved line portion 597 can be provided by filling inpixel data between the curved line portions 554 and 555. The resultingimage 595 which is obtained advantageously includes the line portionswhich were previously obscured. The resulting image 595 can be used increating a more realistic animation when the image is viewed fromdifferent virtual viewpoints.

The resulting image data can be, e.g., stored in memory, output toanother device for further processing, and/or communicated to anotherlocation. Further, note that it may only be desired to remove the lineswithout repairing them. In this case, step 520 can be omitted. Further,image data both with and without the lines can be obtained.

Thus, a method for automatically finding and repairing lines in imagedata of an event is provided. Advantageously, line segments in the maskimage can be automatically detected, the portion of a line segment whichis occluded by the object (e.g., a player) can be automaticallydetermined and the object can be automatically removed.

FIG. 5 b depicts a process for finding straight lines in the line finderand repair process of FIG. 5 a. The process provides details regardingstep 508 of FIG. 5 a. A process for finding straight lines in maskedimage segments begins at step 530. In one possible implementation, step532 includes applying the Hough transform to the center pixels of themasked image segments. The Hough transform is a feature extractiontechnique used in digital image processing. The classical transformidentifies lines in the image, and has been extended to identifyingpositions of arbitrary shapes. The Hough transform can be used to detecta group of pixels that are on a straight line or a smooth curve. See,e.g., U.S. Pat. No. 3,069,654 to Hough, issued Dec. 18, 1962,incorporated herein by reference. The Hough transform parameterizeslines with two parameters, commonly called R and θ (theta). Theparameter R (radius) represents the distance between the line and theorigin, while 0 is the angle of the vector from the origin to a point.The algorithm can use an array called an accumulator to detect theexistence of a line in the original image space. For each pixel and itsneighborhood, the Hough transform determines if there is enough evidenceof an edge at that pixel. If so, it will calculate the parameters (e.g.,R and θ) of that line, and then look for the accumulator's bin or bucketthat the parameters fall into, and increase the value of that bucket. Byfinding the buckets with the highest value, the most likely lines can beextracted, and their (approximate) geometric definitions obtained. Notethat the slope intercept Hough transform (y=mx+b) may be used in somesituations, but it fails for vertical lines, in which case R and θ areused.

Step 534 includes determining a minimum desired line length (LMIN),e.g., in units of pixels. Lines with a smaller length are not detected.Step 536 includes, for each pixel, searching for pixels within aspecified distance, such as ½ LMIN. Step 538 includes determining theradius R and the angle theta (0) for each segment. Step 540 includesbucketing R and theta, and selecting the best bucket. In this manner, astraight line in a mask image can be detected.

FIG. 5 c depicts a process for finding curved lines in the line finderand repair process of FIG. 5 a. The process provides details regardingstep 510 of FIG. 5 a. As with the straight line detection process ofFIG. 5 b, the Hough transform may be used, in one possibleimplementation, to detect curved lines in a masked image. A process forfinding curved lines in masked image segments begins at step 542. Step544 includes finding a tangent angle for remaining pixels after straightlines are found. For example, referring to FIG. 5 g, a tangent angle “A”is depicted for a pixel represented by a point 582. A tangent angle canbe determined for the pixel represented by a point 583, and so on. Step546 includes chaining together pixels with slowly changing tangent anglevalues. For example, an appropriate threshold angle can be determinedaccording to the sports event at issue, camera registration settings andother factors, so that curves which change at a rate which is above thethreshold are discarded, while curves which change at a rate which isbelow the threshold are not discarded, but are processed and repaired ifnecessary in the line finder process of FIG. 5 a.

FIG. 6 a depicts a player finder process. Generally, this process can beused to detect objects in an image, where the objects have particularcharacteristics, e.g., size, shape, aspect ratio, density and colorprofile. In one approach, the players are extracted from an image usingan operator assisted color mask method after the field lines have beenremoved. This approach can provide benefits compared to a differencemethod, for instance, in which the moving components of a frame aredetected. However, the difference method or other techniques mayalternatively be used.

In an example implementation, players in a sports event are detected.The player finder process begins at step 600. Step 602 includescapturing an image of a live event. For example, FIG. 6 b depicts avideo image 640 which is provided in a user interface seen by anoperator. The user interface includes a set of tabs. Each tab can beselected by the operator to perform a different function. The currentlyselected tab 643 is entitled “Find Players.” Step 604 includes setting acolor matte. For example, FIG. 6 d depicts a color matte image 660 ofthe video image of FIG. 6 b. The image includes the field lines 664 anda field 666. The field lines 664, which are white in the original image,are depicted as being dark. Similarly, the field 666, which is a darkgreen in the original image, is depicted as being light. The currentlyselected tab 662 is entitled “Color Matte.” A color matter image isusually black and white. What is shown in FIG. 6 d is an overlay wherethe areas that would normally be black in the color matte are drawn inyellow over the original image. The yellow appears as a lighter color.The color of the lines in the image was not changed. The lines justappear dark next to the yellow.

Step 606 includes setting a camera registration. For example, FIG. 6 edepicts a user interface 670 which includes the video image of FIG. 6 band a camera registration schematic 674. The camera registrationschematic 674 depicts x, y, and z coordinates, as well as a field ofview value, for a camera which provided the image. Further, a diagram ofthe playing field 676 includes registration points 680-688. The operatorcan use a mouse or other pointing device to select one of the points inthe diagram 676 and then select a corresponding point in the image. Forexample, points 680-688 in the diagram 676 correspond to points 690-698,respectively, in the video image. In practice, selecting a few points isusually sufficient to register the camera. When the camera isregistered, a transformation matrix is defined for converting from alocation in pixel space to a location in world coordinates or othercoordinate system. The reverse transformation can also be performed,e.g., world coordinates to pixel space/screen pixels. Moreover, notethat it is helpful to perform camera registration for a specific imagewhich is used to provide an animation at different virtual viewpoints.Another approach is to perform calibration on an initial image and usethat calibration for a subsequent image which is used to provide theanimation.

Step 608 includes running a line finder and repair process, discussedfurther in connection with FIG. 5 a, to remove lines from a mask imageand/or to repair occluded portions of lines. For example, it may only bedesired to remove the lines without repairing them before finding theblobs. In this case, step 520 of FIG. 5 a can be omitted. Step 610includes running a blob finding algorithm to detect players in theimage. A blob finding algorithm refers to any algorithm which can detectan object in an image, where the object has specified characteristics.In one example implementation, the cvBlobsLib source code, availablefrom Intel's Open Source Computer Vision Library, can be used. Step 612includes determining a bounding box for each blob, e.g., according tothe height and width of each blob. For example, FIG. 6 b depictsbounding boxes 644, 645 and 647-650. Step 614 includes transforming thebox height in pixels to a real world player height based on the cameraregistration. For example, a certain pixel height in image space willcorrespond to a certain player height in feet. The height variesdepending on where the player is in the image. An average player heightcan be used. Note that a player can be detected from a single framewithout the need to track players across multiple video frames.

At decision step 616, if the blob is too small, e.g., its height is lessthan the average height of a player by a threshold amount, e.g., 25%,the blob is discarded at step 632. At decision step 618, if the blob istoo large, e.g., its height is greater than the average height of aplayer by a threshold amount, e.g., 25%, an erode filter is run on theblob at step 620. An erode filter tends to reduce the size of the blobso that smaller features are removed, leaving one or more centralmasses. This can be useful, e.g., when two players which are connectedby a field line are initially identified as one blob. The erode filterwill tend to remove the line while leaving the main portions of theplayers so that they can be re-identified as separate players by theblob finding algorithm. Other times, a logo on the field may bemis-identified as a player. Step 622 indicates that steps 610-620 can berepeated up to a specified number (n) of times. If the blob is still toolarge, it is discarded at step 632.

If the blob is not too small or large, that is, it is within the sizerange which is expected for the object which is being detected, e.g., aplayer, a decision is made at step 624 as to whether the blob aspectratio (e.g., height to width ratio of the blob bounding box) is withinspecified tolerances. For example, an average aspect ratio may beascertained through previous studies. If the aspect ratio is within,e.g., +/−25% of the average aspect ratio, a further check is performed.Note that an aspect ratio of a player may be out of limits if the playeris on the ground, for instance (e.g., player 646 is on the ground). Insuch a case, the operator can manually select the player via the userinterface of FIG. 6 b. A density check is performed at decision step626. The density of a blob can indicate what portion of a bounding boxis taken up by the blob, e.g., the identified object, e.g., as a ratioof white pixels to total bounding box size. For example, a blobdetecting algorithm might initially detect that a field line which has aheight similar to a player is a player. A density check would identifythis error since a white field line against a background of the greenfield would have a low density which is not within, e.g., +/−25% of theexpected range. If the aspect ratio or density is not acceptable, theblob is discarded at step 632.

At step 627, a color profile of the blob is checked. Generally, theplayer finder process, or any analogous object finding process, can usecolor profiles to assist in detecting and distinguishing players orother objects. In one approach, a color profile or signature involves adistribution of color data of an image of an object across a color spacepalette. The color profile can be expressed by a histogram, where eachvertical bar indicates, by its height, a number of pixels which havebeen classified into a particular bin or range of colors in a colorspace. Most color spaces include multiple components. For example, a24-bit implementation of the RGB color space includes 8-bits (256levels, labeled from 0-255) each for red, green and blue components. Acolor profile can include bins which each encompass a range of colorcomponents. In one possible approach, each detected blob can be furtherprocessed by obtaining its color profile and comparing the color profileto an expected color profile. If the detected color profile falls withinan expected range of color profiles, the detected blob may be deemed tobe a detected player, for instance. Further, the expected color profilecan be set for different teams in a sport event, for instance, based ontheir uniform colors. If the color profile is acceptable, the blob isaccepted at step 628 as accurately identifying a player or other objectof interest. Otherwise, the blob is discarded at step 632.

At step 630, the operator can provide manual adjustments, if necessary.For example, the bounding box 644 (FIG. 6 b) has misidentified twoplayers as being one player since they are overlapping. In this case,the operator can remove the current bounding box 644 and use a pointingdevice to draw new bounding boxes 651 and 652 around each player, asindicated in FIG. 6 c. FIG. 6 c depicts a video image after an operatorhas separated out two players from a common bounding box which wasprovided by the process of FIG. 6 a. The operator has also manuallyadded a bounding box 653 for player 646.

Note that in this and other examples, the objects need not be players ina sporting event. The objects can be other participants in a sportingevent, such as referees. Further, non-human objects may participate in asporting event, either with or without humans, such as a horse in a polocontest or horse race. Also, a sporting event can be indoors oroutdoors. Further, the event need not be a sporting event but can be anytype of event in which physical movement of objects is of interest. Asanother example, an event can be analyzed for security purposes,accident reconstruction purposes and so forth.

FIG. 7 a depicts a process for building a missing portion of an occludedplayer. As mentioned, objects of interest such as players in a sportsevent may sometimes occlude one another in the action of the game. Insuch cases, the realism of an image which is rendered from differentvirtual viewpoints can be enhanced by rebuilding an image of a player toadd in any missing features, such as arms or legs or other body parts.For example, in the image 640 of FIG. 6 c, the player in bounding box651 is occluded partly by the player in bounding box 644.

The occluded player builder process begins at step 700. Step 702includes displaying images of players located by the player finderprocess of FIG. 6 a on a user interface. For example, FIG. 7 b depicts auser interface 720 for substituting a missing portion of an occludedplayer. The interface is displayed when an “Edit Players” tab 721 isselected by the operator. In a display region 722, images 724, 726, 728,730, 732, 734, 736 and 738 are displayed, one for each player which islocated by the player finder process. The player images correspond tothose in FIG. 6 c. Some images, such as images 726, 728, 736 and 738depict more than one player, although a different player is in thecenter of each image. For example, images 726 and 728 include the sametwo players, and images 736 and 738 include the same two players. Theoperator can configure the size of each player image. The operator canuse tools, such as cropping and paint brush tools, to remove anextraneous player as well as any extraneous images such as field lines,such as shown in images 726, 728 and 730. Image 724 is currentlyselected, and is shown in detail in a display region 739. The userinterface 720 includes other tools such as paintbrushes 746 and 747 forpainting in portions of the player in the display region 739, cut andpaste tool 748, library select button 750 for accessing a library ofimages, up/down positioning tool 752 for moving images in the displayregion 739, and ground level and pivot point tool 754 for setting aground level and pivot point of a player.

Step 704 (FIG. 7 a) includes the operator adjusting the ground level andpivot point for an image if necessary. For example, for the player 728,the ground level is represented by a horizontal line 756 and a pivotpoint, which defines a pivot/rotation axis, is represented by a smallervertical line 758. The ground level and pivot point are bothconfigurable by the operator, such as by dragging the lines using apointing device. In one approach, an automatic algorithm may be used toidentify the ground level as being at the bottom of the player image,while the pivot point is set automatically at a midpoint of the player'swidth. This is suitable for rendering an animation of the players atdifferent virtual viewpoints in most cases. However, in some cases, theplayer may be jumping in the air, for instance, in which case, theground level should be below the player's image in order for the imageto be more realistic when viewed from different virtual viewpoints. Theoperator can set the ground level and/or pivot point accordingly byreferring to the original image if necessary.

Step 706 includes the operator selecting an image in which a player isoccluded. In the example of FIG. 7 c, this is image 738. Step 708includes the operator cropping out the occluded player. When theoperator uses the interface tools to crop out the overlapping player,the remaining player will appear with no leg, as indicated in FIG. 7 c.FIG. 7 c depicts the user interface 720 showing a player with a missingportion, e.g., leg. The player from image 738 is selected and thereforeappears in the display region 739. Further, the operator has selectedthe library icon 750 so that a library 740 of images for providing themissing portion is displayed. The library 740 provides images which theoperator can use in repairing the occluded player. A tab 774, “Library”,can be selected by the operator to access prior images of the players,e.g., typically from the same sporting event, or from prior sportingevents. A tab 742, “Current”, which is currently selected, can beselected by the operator to access images of the players from thecurrent frame. The players 734, 730, 728, 732, 736, 724 and 726 are thesame as the like-numbered images in the display region 722.

Step 710 includes the operator selecting a current or previous playerimage which is suitable for repairing the occluded player. Here, image732 of the library 740 is selected by the operator, as indicated by thedashed lines. Through use of judgment, the operator believes that theleg of the player 732 can be combined with the player image in thedisplay region 739. When the image 732 is selected, the image is movedto the display region 739. FIG. 7 d depicts the user interface of FIG. 7c showing the selected library image 732 combined with the player withthe missing portion. The operator can use tools to scale and positionthe image 732 so that its leg is in a desired position, and has adesired size, relative to the occluded player. Step 712 includes theoperator selecting a desired portion of the current or previous playerimage and combining it with the occluded player. FIG. 7 e depicts theuser interface of FIG. 7 d after repairing the player with the missingportion. A box 760 indicates a portion of the library image 732 whichwas cut and combined with the occluded player. Additionally, theoperator painted in a foot portion 762 of the occluded player, inaddition to providing a ground level 764 and a pivot point 766 for theoccluded player. A portion of the cropped out portion of the libraryimage 732 appears behind the occluded player so that an upper portion ofthe occluded player's leg is visible and appears to transition naturallyinto the added in leg.

Step 714 includes replacing the original image of the occluded playerwith the repaired player. Once the repaired player has been built, theoperator saves the image and it is used in place of the originaloccluded image in texturing a model of the player when renderingdifferent virtual viewpoints. Again, this procedure adds realism to thevirtual viewpoints.

FIG. 8 a depicts a process for building an animation. Step 800 includesbeginning to build an animation. Step 802 includes recording images of alive event, such as images from a video broadcast of the event. At step804, an operator identifies a selected image to be used in an animation.This can occur essentially in real time as the event occurs, or at alater time. The selected image can be a standard resolution or highresolution image, as discussed in connection with FIG. 4.

In one approach, the event is a sports event in which there are periodicbreaks. During the action of the event, an operator can note certaintimes in which events of interest occur, and can review those eventslater, such as during breaks in the action, to select an image to beused. For example, see the “Record Video” tab in the user interface ofFIG. 6 b. The operator can work under other tabs of the user interfacewhile the video is being recorded. At step 806, the color matte is set,as explained further in connection with FIG. 6 d. At step 808, cameraregistration is set, as explained further in connection with FIG. 6 e.At step 810, a line finder and repair process is performed, as explainedfurther in connection with FIGS. 5 a-j. At step 812, a player finderprocess is performed, as explained further in connection with FIGS. 6a-c. At step 814, an occluded player builder process is performed, asexplained further in connection with FIGS. 7 a-e.

At step 816, a repair field process is performed. For example, FIG. 8 edepicts a user interface 840 for repairing a playing field. After theplayers are identified by the player finder process, their images can beremoved to provide an image which provides the background field andlines. This process may result in some artifacts, such as lines 842, 844and 846, in addition to gaps in the actual field lines, such as gap 848.In one possible approach, the field can be repaired by running the linefinder and repair process of step 810. In another approach, the operatorcan use drawing and editing tools to repair the field, such as bycopying areas of the field over the errant lines to cover those lines,and copying and aligning portions of the image which have a line, orpainting in the line, to fill in the gap 848. FIG. 8 f depicts the userinterface 840 of FIG. 8 e after the playing field has been repaired,showing, e.g., how the gap 848 has been filled in.

At step 818, a model can then be run which includes the video texture ofthe repaired field applied to a 3d model of the event facility such as asport stadium, in addition to 2d or 3d models of the players or otherobjects which are textured using the image data. The model can berendered from different virtual viewpoints which differ from theviewpoint of the camera which provided the original image on which themodel is based. For example, the virtual viewpoints can be offset leftor right, up or down, from the camera's viewpoint, up to a certainamount at which distortion becomes unacceptable. Further, other featuressuch as zooming in and out can be provided. Step 818 is explainedfurther in connection with FIG. 9 a. At step 820, the operator selects asequence of virtual viewpoints which are generated by the model. Forexample, the operator may select virtual viewpoints which give theimpression that the viewer is flying around and over the players on thefield. At step 822, an animation is provided based on the selectedvirtual viewpoints. The animation can automatically fill in informationfor transitions between the selected viewpoints. For example, assume theviewpoint of the original image is as depicted in FIG. 9 e, a firstselected virtual viewpoint represent an approximately 20 degree rotationto the left of the camera viewpoint, as depicted in FIG. 9 f, and asecond selected virtual viewpoint represents an approximately 20 degreerotation to the right of the camera viewpoint, as depicted in FIG. 9 g.In this case, the animation can provide transitions from the cameraviewpoint to the first selected virtual viewpoint and then to the secondselected virtual viewpoint. The amount of time of the transitions andthe time spent at each virtual viewpoint can be configured by theoperator or set to default values.

Generally, the animation can be built from one or more images of anevent such as a sporting event or other live event. However, theanimation can be built at any time, including at the time of the eventor after the event, e.g., days or years later, from one or more recordedimages of the event. Moreover, the event can be a static event in whichthere is no movement, such as the capturing of an image such as aphotograph of scenery or people in a static pose, or a dynamic eventwhich involves movement, such as players running on a field. Theanimation can be used in many different applications, in addition toproviding interesting views in sports competitions, includingsurveillance and security monitoring applications, scientificapplications, analysis of tennis or golf swing, and so forth.

FIG. 8 b depicts a process for providing a presentation. Once theanimation has been developed, it can be used in a video presentationwith video images before and/or after the image which is the basis forthe animation. The presentation begins at step 830. At step 831, imagesbefore the selected image used for the animation, e.g., pre-animationimages, are played. For example, this can be a few seconds of videobefore an important play in a sports event. This sets up the context ofthe animation. At step 832, the animation is played. At step 828, imagesafter the selected image used for the animation, e.g., post-animationimages, are played. To provide a smooth transition, the first image ofthe animation can blend in with, and/or be the same as, a last image ofthe pre-animation sequence of images. Similarly, the last image of theanimation can blend in with, and/or be the same as, a first image of thepost-animation sequence of images. In one approach, the animation beginsand ends at the same virtual viewpoint. The animation can also be playedalone, without the pre- and/or post-images.

FIG. 8 c depicts a process for providing a presentation using cameraswith different viewpoints. It is possible for an animation to start andend at different virtual viewpoints. For example, images may be obtainedfrom first and second cameras having different viewpoints (step 830).The cameras may be aimed at an event from different respectivelocations, or may be co-located but aimed differently. An animation canbe prepared from an image from the first or second camera (step 831). Apresentation can also be prepared using images from the first camera,e.g., which depict the real viewpoint of the first camera, followed bythe animation, followed by images from the second camera, e.g., whichdepict the real viewpoint of the second camera (step 832). The first andsecond cameras can be broadcast video cameras, for instance.

In this case, the animation can start at a virtual viewpoint whichcorresponds to the real viewpoint of the first camera, transition to asequence of other virtual viewpoints, and end at a virtual viewpointwhich corresponds to the real viewpoint of the second camera. This canprovide an even more interesting and dynamic presentation for theviewer. For example, the viewer may seem to view the event from one sideof the field, fly over or around the field, then continue viewing theevent from the other side of the field. FIG. 8 d depicts a process forproviding a presentation using standard and high resolution images. Asdiscussed above, e.g., in connection with FIG. 4 and FIG. 5 a, step 500,a high resolution camera and a standard camera can be used to obtainimages of an event (step 834). When it is desired to provide ananimation which depicts different virtual viewpoints, an operator canprovide a command via an appropriate user interface, for instance, whichidentifies a specific image of interest from the standard camera (step835). A corresponding image from the high resolution camera can furtherbe identified from the identified image of the standard camera, e.g.,based on a corresponding time (step 836). This can be doneautomatically, for instance. The image from the high resolution cameracan then be used to provide a sequence of different virtual viewpointsin an animation (step 837). Using a high resolution camera for thedifferent virtual viewpoints provides various benefits, as mentionedpreviously. Further, a presentation can be created in which theanimation with different virtual viewpoints which are obtained using animage from the high resolution camera is followed by images of thestandard camera. Alternatively, or additionally, in the presentation,the animation is preceded by images of the standard camera (step 838).

It is also possible to have multiple freeze points in a single animationor replay. For example, an animation can be prepared from multipleimages from the first and/or second camera.

In one approach, the standard camera is a video camera such as an analogbroadcast video camera and the high resolution camera is a digital stillcamera or a digital video camera. In another approach, the standardcamera is a digital broadcast video camera and the high resolutioncamera is a digital still camera. Optionally, the standard camera andthe high resolution camera are co-located.

FIG. 9 a depicts details of a process for rendering virtual viewpoints.Step 900 includes beginning creation of a model, which can be a 3d modelof an event facility such as a sport stadium, in addition to 2d or 3dmodels of the players or other objects. Step 902 includes providing astadium model with texture. For example, FIG. 9 d depicts a userinterface 940 for providing a texture of a 3d model. A “Stadium Texture”tab 941 is selected by the operator. A diagram 944 depicts a model of astadium which can be configured by the operator, such as by enteringinformation regarding the length and width of the playing field, thedistance from the field to the grandstands on each side of the field,and the depth and angle of the grandstands. From this information, a 3dvirtual model of the stadium can be created. Further, video texture canbe applied to the model from images which are captured by one or morecameras at the stadium. Display region 942 depicts a current videotexture of a stadium. A user interface device such as a button 943allows the operator to update the texture of a stadium. Or, updating canoccur automatically such as when a specified event occurs. See also FIG.9 c and the associated description.

Step 903 includes detecting an object in an image which is to bereplaced by a virtual 3d object. For example, a goal post or other goalstructure (e.g., as used in American football, soccer, hockey,basketball or lacrosse) may be detected in a sport event. The detectionmay be made automatically, e.g., without operator input, using imagerecognition techniques and knowledge of characteristics of the objectand its location in the live event. For example, the known physicalshape and color of the object can be used to assist detection. Further,the known predetermined location of the object in the live event andcamera registration data can be used to assist detection. As an example,a goal post in a soccer game is typically white and has a specifiedsize, shape and location in the live event in accordance with gameregulations. The object can therefore be detected by examining pixels ina portion of the image which corresponds to the predetermined locationin the live event. Once the object is detected, the pixels which make upthe object can be removed. Optionally, the removed pixels can beautomatically blended in with surrounding pixels, which might be greenpixels of the field. Or some manual editing may be performed. However,generally such blending in or editing may not be needed as the virtualgoal post which is used in the model accurately replaces the removedpixels. In one approach, the pixels are only replaced when viewing fromthe original (non-virtual) camera angle. Optionally, step 903 can beskipped.

Step 904 includes providing one or more 3d virtual objects in the model.For example, the image 950 of FIG. 9 e includes a virtual goalpost 955,which can be created using known dimensions and characteristics of anactual goalpost. Note that the viewpoint of FIG. 9 e is the same as thecamera's viewpoint, so the virtual goal post essentially blends in withthe image of the actual goalpost. The use of a virtual object, e.g., a3d model of an object, such as a goalpost in the overall model providesgreater realism when the model is viewed from different virtualviewpoints. In one approach, the virtual object does not have videotexture applied to it from images which are captured by one or morecameras. For example, the color white for a goal post can be specifiedfrom a palette of colors rather than taken from the white pixels in animage. In contrast, the textured 3d model of the event has textureapplied from one or more camera-captured images of the event. Thevirtual object can be located at a predetermined location in the liveevent, e.g., at the end boundary lines in a soccer game, and/or at alocation which is based on the detection of step 903.

Step 906 includes providing 2d or 3d models of players with texture fromthe selected image which is used in the model. A 2d model can providesufficient realism in many cases, particularly when the models of theplayers are rotated based on an angle of rotation of the virtualviewpoint. A 3d model can provide greater realism as well as allowingthe players to be viewed from essentially any virtual viewpoint. In oneapproach, discussed further below, a 3d kinematics models of the playerscan be used. In providing the player models, video texture from one ormore images from one or more cameras can be applied to the models. Forexample, multiple cameras arranged at different locations can be used,in which case texture from each camera can be combined. For example, fora virtual viewpoint which is the same as the viewpoint of a firstcamera, texture from an image of the player which is provided by thefirst camera can be applied to a player model. As the virtual viewpointtransitions away from the viewpoint of the first camera and toward theviewpoint of a second camera, texture from images of the player whichare provided by both the first and second cameras can be applied to theplayer model. For example, more texture is applied from the imageprovided by the second camera as the virtual viewpoint becomes closer tothe viewpoint of the second camera.

If the virtual viewpoint transitions to a viewpoint which results in toomuch distortion, the texture on the object can be replaced by a defaulttexture such as a fixed color. For instance, if only one camera isavailable, and it provides texture for the front of a player, thistexture should be adequate for virtual viewpoints which show the frontof the player. However, the camera's image data will not be able toprovide texture if the virtual viewpoint shows the back of the player.In this situation, the back of the player may be rendered by a fixedcolor. Or, a default player texture a texture from another player may beused to render the back of the player.

Step 908 includes rendering the stadium model, virtual 3d objects andmodels of players from selected viewpoints. For example, FIG. 9 edepicts a rendering of the model from the virtual viewpoint whichcorresponds to a camera's viewpoint. FIGS. 9 f and 9 g depict renderingsof the model from virtual viewpoint which are to the left and right,respectively, of the camera's viewpoint. Note that the realisticappearance of the virtual goalpost 955 in FIGS. 9 e and 9 h. In FIG. 9f, image data of the actual goalpost 961 is depicted to show thedistortion that would occur if the virtual goalpost 955 was not used. Inpractice, the actual goalpost can be edited out by an operator, or leftin if desired.

Various techniques for rendering different virtual viewpoints and forproviding 2d or 3d models of humans or other objects can be used. Forexample, Hoiem et al., “Automatic Photo Pop-up,” ACM SIGGRAPH 2005,incorporated herein by reference, discusses creating a 3d model from asingle image. U.S. Pat. No. 5,850,352 to Moezzi et al., issued Dec. 15,1998, incorporated herein by reference, discusses generating a 3d videomosaic from multiple video views of a scene. U.S. Pat. No. 6,390,933 toSharir et al., issued Apr. 30, 2002, incorporated herein by reference,discusses generating a 3d video mosaic from multiple video views of ascene. US2005/0018045, published Jan. 27, 2005, titled “VideoProcessing,” incorporated herein by reference, discusses rendering aview of a scene from a selected viewpoint using image data from a realimage. U.S. Pat. No. 7,289,648 to Liu, issued Oct. 30, 2007,incorporated herein by reference, discusses modeling three dimensionalobjects from a single image. US2002/0158873 to Williamson, publishedOct. 31, 2002, incorporated herein by reference, discusses insertingvideo images into a virtual environment.

Other examples are provided in Ahmed et al., “Automatic Generation ofPersonalized Human Avatars from Multi-view Video,” Proc. of the ACMSymp. on Virtual Reality Software and Technology, 2005, pp. 257-260;Malerczyk et al., “3D Reconstruction of Sports Events for Digital TV,”Journal of WSCG (Winter School on Computer Graphics), vol. 11., no. 1.,February 2003; Remondino et al., “Human Motion Reconstruction andAnimation from Video Sequences,” 17th Int. Conf. on Computer Animationand Social Agents (CASA2004), pp. 347-354, July 2004; and W. Lee et al.,“Generating Animatable 3D Virtual Humans from Photographs,” Proc.Eurographics 2000, Vol. 19, No. 3, pp. 1-10, August 2000, each of whichis incorporated herein by reference.

Generally, 3d kinematics models model a human based on movement ofdifferent parts of the body. Kinematics models recognize that parts ofthe body can move in a known manner relative to one another withincertain limitations. Furthermore, based on the event, certain movementscan be modeled. For example, for a soccer game, movements such asrunning, kicking and so forth can be modeled. It may not be necessary tomodel all possible movements. Further, in one approach, a model can beprovided which represents a generic player which has average physicalcharacteristics, such as height and weight. It is also possible toprovide different kinematics models for different sizes of players,e.g., small, medium and large. For some sporting events such as Americanfootball or hockey, where the players wear helmets, individualcharacteristics such as facial appearance are often hidden. In suchcases, a generic model may be sufficiently realistic. However, it isalso possible to provide kinematics models which are customized toindividual players, e.g., including facial appearance, hair, skin color,presence of tattoos, and so forth of individual players. Further,clothing such as uniforms of different teams can be modelled.

Further, video texture from one or more images can be applied to such 3dmodels to provide enhanced realism in an animation. For example, in oneapproach, a 3d kinematics model of a player in a sport event is texturedusing image data from one or more cameras, and the textured 3dkinematics model is combined with a textured 3d model of the stadium todepict different virtual viewpoints. Thus, the same image which is usedto provide a virtual viewpoint can be used to texture a kinematicsmodel, in one possible approach. The optimal texturing of a 3dkinematics model can be determined using an optimization process.

FIG. 9 b depicts a process for rotating and fading out players based onan angle of a virtual viewpoint. Step 920 includes rotating models ofthe players based on an angle of a virtual viewpoint. To provideadditional realism, the 2d or 3d models of the players can be rotated byan angle which is based on the rotation of the virtual viewpoint, thatis, an angular offset of the virtual viewpoint from the camera'sviewpoint. The rotation can be about the pivot point of each player, asdiscussed in connection with FIGS. 7 a-e. For example, the angle bywhich a player is rotated can be a fraction, e.g., 75% of the angularoffset. Or, the angle by which the player is rotated can be a generalfunction of the angular offset. In one approach, the rotation of theplayer is relatively greater for lower angular offset and is graduallyless for higher angular offsets. For example, for an angular offset of0-30 degrees, the rotation of the player can vary gradually from 90% (at0 degrees) to 70% (at 30 degrees) of the offset.

Step 922 includes fading out one or more models of players based on theangle of the virtual viewpoint. As the angular offset of the virtualviewpoint becomes large, distortion can occur in the image as image datais not available to accurately depict a player. Generally, thisconstraint depends on the number and placement of cameras. It can beuseful to fade out, e.g., partially or fully remove the image of aplayer, instantly or over a specified time period, e.g., in which thefading is apparent to a human viewer, based on an angular offset of thevirtual viewpoint from an angle of the camera's viewpoint, based on thevirtual viewpoint exceeding a specified difference from the viewpoint ofthe camera in regard to some other parameter, or based on othercriteria. For example, an object can be at least partially faded outover multiple virtual viewpoints. Further, step 924 includes fading outa first player while still displaying a second player, in a givenvirtual viewpoint, and step 926 includes providing a marker in place ofa faded out player. Generally, it can be useful to fade out one objectbut not another based on an angular offset of the virtual viewpoint. Forexample, a first player which does not occlude a second player in afirst virtual viewpoint may begin to occlude the second player in asecond virtual viewpoint. For instance, the virtual viewpoints of FIGS.9 e and 9 f depict players 948 and 949 as distinct players which do notocclude one another. However, the virtual viewpoint of FIG. 9 g depictsplayer 949 at least partly occluding player 948. This may not bedesirable if it is desired to focus on player 948. FIG. 9 h depicts thesame virtual viewpoint of FIG. 9 g, but player 949 has been faded outand replaced by a marker 981. As a result, the player 948 can be seenfrom this virtual viewpoint without being occluded. To achieve this, inone approach, the operator can select the virtual viewpoint of FIG. 9 hand indicate via a user interface that player 949 is to be removed andreplace by a marker, or just removed and not replaced by any marker.When the animation is subsequently played, player 949 will be faded outwhen the virtual viewpoint of FIG. 9 h is reached.

In another possible approach, the model may be configured so that anyplayer which is occluding another player is faded out. Or, only selectedplayers may be identified to be faded out when they occlude anotherplayer. Or, only selected players may be identified so that otherplayers which occlude them are faded out when the occlusion occurs. Thedetermination of whether one player occludes another can be madeautomatically by the model, such as by determining if there areoverlapping lines of position from each player to an origin of thevirtual viewpoint. The degree of occlusion can further be factored in todetermining whether and when an occluding player should be faded out.

In another example, consider an image of a baseball game in a virtualviewpoint which shows the pitcher, catcher and umpire. As the virtualviewpoint transitions to a viewpoint which is behind the umpire andcatcher, the umpire and catcher can be faded out in order to see thepitcher and the pitched ball.

Fading of selected players is an advantage in that it allows the viewerto better see how the players align themselves on the field, who isblocking who, and so forth.

FIG. 9 c depicts a process for texturing a 3d model. As discussed inconnection with FIG. 9 d, a user interface 940 displays a video texturein a display region 942 which is applied to a stadium or other eventfacility or location. Step 930 includes building a stadium model. Forexample, a diagram 944 allows an operator to specify a geometry of thestadium for use in the model. In the current example, the length of thefield is 120.19 yards, the width is 75 yards, the distance from thefield to the advertising boards of the grandstands on each side of thefield is 1 yard (top), and 4 yards (right, bottom and left sides). Thedepth and angle of the grandstands is 30 yards and 33 degrees (top), 25yards and 33 degrees (right side), 20 yards and 10 degrees (bottom), and25 yards and 33 degrees (left side). While the example provided shows astadium with a rectangular configuration, other configurations may beprovided as well. Once the geometry is specified, video texture from oneor more cameras can be applied (step 932), e.g., to obtain an initialtextured 3d model of the stadium or other event facility. Note thatapplying the texture to a 3d model results in greater realism thanapplying texture to a plane.

For instance, video texture can be applied from images which areobtained prior to, and/or during the event. At step 934, the texture isupdated, e.g., based on a user command (on demand), or automaticallybased on detection of a specified event. A user interface device such asa button 943 allows the operator to update the texture of a stadium,such as from a current image. An updated textured 3d model of the eventcan be obtained by updating the initial textured 3d model. Moreover,updating can occur automatically when a specified event occurs. Thespecified event can be a specified time, e.g., after a specified periodhas passed since a last update or at specified times of day, e.g.,relative to sunset or sunrise. The appearance of a stadium can changedue to various factors, such as changing lighting in the stadium (e.g.,due to presence of sun or clouds, or due to use or non-use of stadiumelectric lights), changes in the number of fans in the stands, changesin advertisements or signs in the stadium, movement of a roof of thestadium or other reconfiguration of the stadium or other event site, andso forth. In one approach, the texture is updated when an image used inan animation is captured. The determination of whether a specified eventoccurs which should trigger automatic updating of the texturing can beachieved in different ways, such as a light sensor to detect ambientlight level, or a sensor which detects whether stadium lights have beenturned on, for instance. Similarly, a timing device or process can beused to determine if a specified period has passed since last update ora specified time of day is reached.

It can be helpful to texture the model before a sports event begins,when there are no players and on the field and therefore no occlusions.

FIG. 9 e, discussed earlier, depicts an initial image in an animationfrom a virtual viewpoint which corresponds to the perspective of acamera viewpoint. The “Animation” tab 951 is selected by the operator.The user interface 950 provides the image, which includes players946-949, a ball 945, and a 3d model goalpost 955. Further, tools areprovided for creating an animation. For example, a time line 954indicates an elapsed time of the animation, which is currently zero inthis display. An icon 953 can be selected by the operator to designatethe current image as the first image of the animation. A bar 952 depictsa sequence of selected images, once they are selected, and allows theoperator to set the amount of time each image should be display as wellas the amount of time between different images.

FIG. 9 f, discussed earlier, depicts a second image in an animationwhich is obtained from a virtual viewpoint which is to the left of thecamera viewpoint of FIG. 9 e as well as being zoomed in somewhat. In theuser interface 960, the bar 952 indicates that four other images havebeen selected for the animation, based on the icons 953, 955, 956 and957. The operator can click on any of the icons to view thecorresponding image. Further, the operator can manipulate the virtualviewpoint such as by clicking on a portion of the image and dragging theimage. Note that the ball 945 can also be provided as a virtual 3d modelwhich is positioned by the operator. Also, note that the player 947 canbe fully seen. This player is a repaired player in which the missing legwas added in, as discussed previously. FIG. 9 g, discussed earlier,depicts a third image in an animation which is obtained from a virtualviewpoint which is to the right of the camera viewpoint of FIG. 9 e.FIG. 9 h, discussed earlier, depicts the third image of FIG. 9 g inwhich one of the players is replaced by a marker 981.

FIG. 10 a depicts a process for enabling a user to run an animation. Inone approach, an animation which provides different virtual viewpointsof a live event is created by an operator, such as a technician, who isassociated with a television broadcast company, and the animation isprovided as part of the broadcast, such as during a replay of aparticular event of interest, or during a half time analysis show. Theviewer/user at his or her home may not have any control of the creationof playback of the animation in this approach. In another approach, theuser can be provided with such a capability. This can provided addedentertainment to the user. Further, a service provider may charge a feefor this added capability, resulting in additional revenue.

Step 1000 includes obtaining images of a live event. Step 1002 includesproviding a model for one or more selected images. For example, this caninclude providing 2d or 3d data for each player, including associatedtexture data from the image, as well as 3d texture data from a stadiumor other event facility and a 3d model of objects such as goal postswhich are to be included. The data can be provided in any suitableformat, and can be accessed by the user to run the model based on theuser's commands. Alternatively, or additionally, an animation which hasalready been created can be provided. Step 1004 includes providing dataidentifying the selected images, such as lower resolution thumbnailimages as preview images. Step 1006 includes transmitting the images andauxiliary data which includes the model and the data identifying theselected images to users. Step 1008 includes a user accessing the imagesand auxiliary data to run the model.

In one possible approach, the images and auxiliary data are provided ina conventional analog or digital television broadcast. In anotherapproach, the image is provided in a television broadcast and theauxiliary data is provided via a separate channel, such as via acomputer network. In this approach, the user may access a web site via ahost computer to access the auxiliary data. See also the user system ofFIG. 3 b, which includes components for providing the functionalitydescribed. The host computer can be separate from a television orincluded with a television. In another approach, both the images and theauxiliary data are provided via a computer network.

FIG. 10 b depicts a user interface which allows a user to select fromavailable animations. During or after a broadcast of an event, the usercan access a menu 1010 of available animations. In the example provided,the menu 1010 identifies a first animation which relates to a 1^(st)quarter goal by team A, and includes a thumbnail image 1012 of theanimation. The thumbnail image can be a camera image or an image from a3d model of the animation. The menu 1010 also identifies a secondanimation which relates to a 2^(nd) quarter blocked kick by team B, andincludes an associated thumbnail image 1014.

FIG. 10 c depicts a user interface 1020 which allows a user to run ananimation. In one approach, the animation has been created and the userhas the ability to start and stop the animation. In another approach,the user has the ability to run the model to view different virtualviewpoints. Optionally, the user is provided with capabilities which aresimilar to those provided to the operator as discussed previously, suchas the capability to identify specific virtual viewpoints and to createan animation from these viewpoints. Here, the user can run the model toview different virtual viewpoints. The user is informed that he or shecan move a cursor to change a point of view, e.g., a virtual viewpoint.This may be considered to be a manual mode in which the user selects theviewpoint. A display region 1022 also gives the user the ability to runa predefined script, select a particular camera and to reset allentries. A predefined script can provide a predefined sequence ofvirtual viewpoints.

FIG. 10 d depicts a user interface 1030 which allows a user to select acamera viewpoint for an animation. In some cases, separate models may beprovided based on separate cameras, in which case the user can select aparticular camera, C1-C3, based on a diagram which shows it location inthe event. In other cases, a single model is provided based on multiplecameras, in which case the user can select a camera which represents aviewpoint of interest.

The user interfaces may be associated with a host computer and/or atleast one processor which is associated with a process-readable storagedevice which stores processor-readable code, in one approach. The atleast one processor executes the processor-readable code to carry outthe functionality described herein.

The foregoing detailed description of the invention has been presentedfor purposes of illustration and description. It is not intended to beexhaustive or to limit the invention to the precise form disclosed. Manymodifications and variations are possible in light of the aboveteaching. The described embodiments were chosen in order to best explainthe principles of the invention and its practical application, tothereby enable others skilled in the art to best utilize the inventionin various embodiments and with various modifications as are suited tothe particular use contemplated. It is intended that the scope of theinvention be defined by the claims appended hereto.

What is claimed is:
 1. A method for providing image data of an eventinvolving participants at an event facility, comprising: receiving atelevision broadcast of the event at a user system, the user systemcomprises a display, a user input device and a host computer, the hostcomputer comprising at least one processor, the television broadcastincludes: (a) video data, including a plurality of camera images of theevent, the plurality of camera images include first and second selectedimages of the event and (b) auxiliary data associated with the videodata, the auxiliary data including: (i) a preview image of the firstselected image, (ii) a model which is based on the first selected imageof the event, and which includes texture data of at least one of theparticipants from the first selected image of the event, (iii) a previewimage of the second selected image, and (iv) a model which is based onthe second selected image of the event, and which includes texture dataof at least one of the participants from the second selected image ofthe event, the model which is based on the first selected image of theevent and the model which is based on the second selected image of theevent include texture data of the event facility; displaying the previewimages of the first and second selected images on the display;receiving, via the user input device, user commands which select thefirst preview image and identify specific virtual viewpoints of theevent; and in response to the user commands, executingprocessor-readable code at the at least one processor to run the modelwhich is based on the first selected image of the event to depict, onthe display, the at least one of the participants from the firstselected image of the event and the event facility, from the specificvirtual viewpoints.
 2. The method of claim 1, wherein: the first andsecond selected images of the event are identified by operator commandsat a production center associated with a television broadcast facilitywhich provides the television broadcast of the event.
 3. The method ofclaim 1, wherein: the user commands include a command for rotatingaround a point.
 4. The method of claim 1, wherein: the user commandsinclude a command for moving a lookout point.
 5. The method of claim 1,wherein: the user commands include a command for zooming in or out. 6.The method of claim 1, wherein: the user system comprises at least oneof a television or a set-top box.
 7. The method of claim 1, wherein: thetexture data of the at least one of the participants from the firstselected image of the event and the texture data of the at least one ofthe participants from the second selected image of the event, comprise2d or 3d texture data.
 8. The method of claim 1, wherein: the texturedata of the event facility includes 3d texture data.
 9. The method ofclaim 1, wherein: the event facility is a stadium, and the texture dataof the event facility includes 3d texture data of the stadium.
 10. Themethod of claim 1, wherein: the model which is based on the firstselected image of the event and the model which is based on the secondselected image of the event, include a 3d model of an object of theevent.
 11. The method of claim 1, wherein: the model which is based onthe first selected image of the event and the model which is based onthe second selected image of the event, include a 3d model of a goalpost of the event.
 12. The method of claim 1, further comprising:creating an animation from the specific virtual viewpoints.
 13. At leastone processor-readable storage device having processor-readable codestored thereon, the processor-readable code is executable by at leastone processor to perform a method for providing image data of an eventinvolving participants at an event facility, the method performedcomprising: receiving a television broadcast of the event at a usersystem, the user system comprises a display, a user input device and ahost computer, the host computer comprising at least one processor, thetelevision broadcast includes: (a) video data, including a plurality ofcamera images of the event, the plurality of camera images include firstand second selected images of the event and (b) auxiliary dataassociated with the video data, the auxiliary data including: (i) apreview image of the first selected image, (ii) a model which is basedon the first selected image of the event, and which includes texturedata of at least one of the participants from the first selected imageof the event, (iii) a preview image of the second selected image, and(iv) a model which is based on the second selected image of the event,and which includes texture data of at least one of the participants fromthe second selected image of the event, the model which is based on thefirst selected image of the event and the model which is based on thesecond selected image of the event include texture data of the eventfacility; displaying the preview images of the first and second selectedimages on the display; receiving, via the user input device, usercommands which select the first preview image and identify specificvirtual viewpoints of the event; and in response to the user commands,executing processor-readable code at the at least one processor to runthe model which is based on the first selected image of the event todepict, on the display, the at least one of the participants from thefirst selected image of the event and the event facility, from thespecific virtual viewpoints.
 14. The at least one processor-readablestorage device of claim 13, wherein: the texture data of the at leastone of the participants from the first selected image of the event andthe texture data of the at least one of the participants from the secondselected image of the event, comprise 2d or 3d texture data; and thetexture data of the event facility includes 3d texture data.
 15. The atleast one processor-readable storage device of claim 13, wherein: thefirst and second selected images of the event are identified by operatorcommands at a production center associated with a television broadcastfacility which provides the television broadcast of the event.
 16. Amethod for providing image data of an event involving participants at anevent facility, comprising: receiving a television broadcast of theevent at a user system, the user system comprises a display, a userinput device and a host computer, the host computer comprising at leastone processor, the television broadcast includes: (a) video data,including a plurality of camera images of the event, the plurality ofcamera images include first and second selected images of the event and(b) auxiliary data associated with the video data, the auxiliary dataincluding: (i) a preview image of the first selected image, (ii) a modelwhich is based on the first selected image of the event, and whichincludes texture data of at least one of the participants from the firstselected image of the event, (iii) a preview image of the secondselected image, and (iv) a model which is based on the second selectedimage of the event, and which includes texture data of at least one ofthe participants from the second selected image of the event, the modelwhich is based on the first selected image of the event and the modelwhich is based on the second selected image of the event include texturedata of the event facility; displaying the preview images of the firstand second selected images on the display; receiving, via the user inputdevice, a user command which selects the first preview image; and inresponse to the user command, executing processor-readable code at theat least one processor to run, according to a predefined script, themodel which is based on the first selected image of the event to depict,on the display, an animation which includes the at least one of theparticipants from the first selected image of the event and the eventfacility, from a predefined sequence of virtual viewpoints.
 17. Themethod of claim 16, wherein: the first and second preview images arebased on the plurality of camera images of the event.
 18. The method ofclaim 16, wherein: the first and second images include an image from theanimation.
 19. The method of claim 16, further comprising: providing theuser with an ability to stop and start the animation.
 20. The method ofclaim 16, wherein: the first and second selected images of the event areidentified by operator commands at a production center associated with atelevision broadcast facility which provides the television broadcast ofthe event.